Sync eng/common directory with azure-sdk-tools for PR
Azure/azure-sdk-tools#13235 See [eng/common
workflow](https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/README.md#workflow)

---------

Co-authored-by: Alitzel Mendez <almend@microsoft.com>

Sync eng/common directory with azure-sdk-tools for PR
Azure/azure-sdk-tools#13235 See [eng/common
workflow](https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/README.md#workflow)

---------

Co-authored-by: Alitzel Mendez <almend@microsoft.com>

* [DNM][WIP][API View] Remove ApiKey usage

* Add -TestAuth flag to verify Bearer token authentication

* TEMP: Enable TestAuthOnly for pipeline testing

* [APIView] Remove testing logs

* Additional clean up

* Keep apikey fallback while migrating

* [APIView] Keep migration to new endpoint

* [APIView] Keep migration to new endpoint

* Feedback

…on (#9501)

- [x] Review Azure SDK PR #13235 pattern for removing API Key
authentication
- [x] Update Create-APIReview.ps1 to remove API Key parameter and add
Bearer token authentication
  - Removed `$APIKey` parameter from script
- Added `Get-ApiViewBearerToken()` function that acquires Azure AD
tokens via `az account get-access-token`
- Updated `Upload-SourceArtifact` to use Bearer token instead of API Key
- Updated `Upload-ReviewTokenFile` to use Bearer token instead of API
Key
- Changed API endpoints from `UploadAutoReview` to `upload` and
`CreateApiReview` to `create` (lowercase)
  - Changed HTTP method from GET to POST for the create endpoint
  - Improved error handling with more detailed error messages
- [x] Update create-apireview.yml to use AzureCLI@2 task instead of
Powershell@2 task
  - Changed task from `Powershell@2` to `AzureCLI@2`
- Added `AzureServiceConnection` parameter with default value "APIView
prod deployment"
  - Removed `-APIKey $(azuresdk-apiview-apikey)` argument
  - Removed `pwsh: true` (not needed with AzureCLI@2)
  - Added `azureSubscription`, `scriptType`, and `scriptLocation` inputs
- [x] Address security concern: removed potentially sensitive token
response from error logging

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Stop using Api Key in Create-ApiReview
script</issue_title>
> <issue_description>We can follow the same pattern as used in
Azure/azure-sdk-tools#13235
> 
> And apply those changes to
https://github.com/microsoft/typespec/blob/main/eng/emitters/scripts/Create-APIReview.ps1
> 
> Also need to update
https://github.com/microsoft/typespec/blob/main/eng/emitters/pipelines/templates/steps/create-apireview.yml</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #9500

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* Add backward compatibility support for constructor accessibility on abstract base types (#9484)

## Problem

Regenerating SDKs from TypeSpec (previously from autorest) changes
constructor accessibility on abstract base types, breaking existing
code. Example from Azure.Search.Documents:

**Previous (autorest):**
```csharp
public abstract partial class SearchIndexerDataIdentity
{
    public SearchIndexerDataIdentity() { }
}
```

**Current (TypeSpec without fix):**
```csharp
public abstract partial class SearchIndexerDataIdentity
{
    private protected SearchIndexerDataIdentity(string odataType) { }
    // Constructor is private protected instead of public
}
```

## Changes

### Core Implementation
- **TypeProvider.ProcessTypeForBackCompatibility**: Extended to process
constructors in addition to methods
- **TypeProvider.BuildConstructorsForBackCompatibility**: New virtual
method for constructor backward compatibility logic
- **ModelProvider.BuildConstructorsForBackCompatibility**: Changes
constructor modifiers from `private protected` to `public` on abstract
base types when the last contract had a public constructor with matching
parameters

### Approach
This implementation changes the accessibility modifier on existing
constructors rather than generating new ones. It only applies when:
1. The type is an abstract base type
2. The last contract had a public constructor
3. The current version generates a `private protected` constructor with
matching parameters (same count, types, and names)

### Generated Code
```csharp
public abstract partial class SearchIndexerDataIdentity
{
    /// <summary> Initializes a new instance of SearchIndexerDataIdentity. </summary>
    public SearchIndexerDataIdentity(string odataType) 
    {
        OdataType = odataType;
    }
}
```

## Testing

- Added `BackCompat_AbstractTypeConstructorAccessibility` test that
verifies constructor modifiers change from `private protected` to
`public`
- All 1231 tests pass
- Updated documentation with new "Model Constructors" section

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>


----

*This section details on the original issue you should resolve*

<issue_title>[Bug]: Backward Compatibility not generating pre-existing
public constructors</issue_title>
<issue_description>### Describe the bug

Pre-existing public constructors should not be missing from the
generated code. This should be another Back Compat scenario. See
[Backward Compatibility
Support](https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/docs/backward-compatibility.md)
for more details.

Generating Azure.Search.Documents have the issue where a public
constructor is missing, for instance, this is what the previously
generated code from autorest looks like:

```csharp
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.

// <auto-generated/>

#nullable disable

using System;
using System.Collections.Generic;

namespace Azure.Search.Documents.Indexes.Models
{
    /// <summary>
    /// Abstract base type for data identities.
    /// Please note <see cref="SearchIndexerDataIdentity"/> is the base class. According to the scenario, a derived class of the base class might need to be assigned here, or this property needs to be casted to one of the possible derived classes.
    /// The available derived classes include <see cref="SearchIndexerDataNoneIdentity"/> and <see cref="SearchIndexerDataUserAssignedIdentity"/>.
    /// </summary>
    public abstract partial class SearchIndexerDataIdentity
    {
        /// <summary>
        /// Keeps track of any properties unknown to the library.
        /// <para>
        /// To assign an object to the value of this property use <see cref="BinaryData.FromObjectAsJson{T}(T, System.Text.Json.JsonSerializerOptions?)"/>.
        /// </para>
        /// <para>
        /// To assign an already formatted json string to this property use <see cref="BinaryData.FromString(string)"/>.
        /// </para>
        /// <para>
        /// Examples:
        /// <list type="bullet">
        /// <item>
        /// <term>BinaryData.FromObjectAsJson("foo")</term>
        /// <description>Creates a payload of "foo".</description>
        /// </item>
        /// <item>
        /// <term>BinaryData.FromString("\"foo\"")</term>
        /// <description>Creates a payload of "foo".</description>
        /// </item>
        /// <item>
        /// <term>BinaryData.FromObjectAsJson(new { key = "value" })</term>
        /// <description>Creates a payload of { "key": "value" }.</description>
        /// </item>
        /// <item>
        /// <term>BinaryData.FromString("{\"key\": \"value\"}")</term>
        /// <description>Creates a payload of { "key": "value" }.</description>
        /// </item>
        /// </list>
        /// </para>
        /// </summary>
        private protected IDictionary<string, BinaryData> _serializedAdditionalRawData;

        /// <summary> Initializes a new instance of <see cref="SearchIndexerDataIdentity"/>. </summary>
        public SearchIndexerDataIdentity()
        {
        }

        /// <summary> Initializes a new instance of <see cref="SearchIndexerDataIdentity"/>. </summary>
        /// <param name="oDataType"> A URI fragment specifying the type of identity. </param>
        /// <param name="serializedAdditionalRawData"> Keeps track of any properties unknown to the library. </param>
        internal SearchIndexerDataIdentity(string oDataType, IDictionary<string, BinaryData> serializedAdditionalRawData)
        {
            ODataType = oDataType;
            _serializedAdditionalRawData = serializedAdditionalRawData;
        }

        /// <summary> A URI fragment specifying the type of identity. </summary>
        internal string ODataType { get; set; }
    }
}
```

and the new generated model looks like:
```csharp
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.

// <auto-generated/>

#nullable disable

using System;
using System.Collections.Generic;

namespace Azure.Search.Documents.Models
{
    /// <summary>
    /// Abstract base type for data identities.
    /// Please note this is the abstract base class. The derived classes available for instantiation are: <see cref="SearchIndexerDataNoneIdentity"/> and <see cref="SearchIndexerDataUserAssignedIdentity"/>.
    /// </summary>
    public abstract partial class SearchIndexerDataIdentity
    {
        /// <summary> Keeps track of any properties unknown to the library. </summary>
        private protected readonly IDictionary<string, BinaryData> _additionalBinaryDataProperties;

        /// <summary> Initializes a new instance of <see cref="SearchIndexerDataIdentity"/>. </summary>
        /// <param name="odataType"> A URI fragment specifying the type of identity. </param>
        private protected SearchIndexerDataIdentity(string odataType)
        {
            OdataType = odataType;
        }

        /// <summary> Initializes a new instance of <see cref="SearchIndexerDataIdentity"/>. </summary>
  ...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9483

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JonathanCrd <17486462+JonathanCrd@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>
Co-authored-by: jolov <jolov@microsoft.com>

* Remove unused `program` param from `isArrayModelType` and `isRecordModelType` (#9336)

## Summary

Added overloads to `isArrayModelType` and `isRecordModelType` that don't
require the unused program parameter. The old signature is deprecated
but still works for backward compatibility.

## Usage
```javascript
// New (preferred)
isArrayModelType(type)
isRecordModelType(type)

// Old (deprecated, still works)
isArrayModelType(program, type)
isRecordModelType(program, type)
```

* Input Type Updates for Xml Serialization Support (#9489)

Adds updates to the input types in preparation for adding xml
serialization support.

contributes to : https://github.com/microsoft/typespec/issues/5645

* [python] correctly deserialize xml errors (#9488)

Co-authored-by: iscai-msft <isabellavcai@gmail.com>

* [specs] add xml error response test (#9499)

Co-authored-by: iscai-msft <isabellavcai@gmail.com>

* Api Version Parameter Reinjection (#9493)

This pull request improves how API version parameters are handled,
specifically ensuring that API version query parameters are correctly
reinjected during pagination scenarios. It also adds a test to validate
this behavior.

**Pagination and Parameter Reinjection Improvements:**

* Added logic to ensure API version parameters (those marked as
`IsApiVersion`) are preserved and reinjected across pagination requests
in the `GetReinjectedParametersMap` method of `RestClientProvider`.
* Updated the `ShouldSkipReinjectedParameter` method to skip both
`maxpagesize` and `api-version` parameters when determining which
parameters to reinject, preventing unnecessary reinjection of these
special parameters.
* Defined a constant for the API version parameter name
(`ApiVersionParameterName`) to improve maintainability and clarity.

**Testing Enhancements:**

* Added a new unit test,
`TestApiVersionParameterReinjectedInCreateNextRequestMethod`, to verify
that the generated client code correctly reinjects the `api-version`
parameter during pagination.

Solves: https://github.com/microsoft/typespec/issues/9492

* Support 3xx redirect status codes in http-client-csharp generator (#9498)

## Plan: Add support for 302 redirect in http-client-csharp

- [x] Understand the issue from migration blocker document
- [x] Identify root cause in RestClientProvider.GetClassifier
- [x] Update GetSuccessStatusCodes to include 3xx status codes
- [x] Add test case for 302 redirect in http-client-csharp
- [x] Validate test passes with changes
- [x] Run broader test suite to ensure no regressions
- [x] Code review and address feedback
- [x] COMPLETE

### Summary

Successfully added support for HTTP 3xx redirect status codes (including
302) to the http-client-csharp emitter.

### Changes Made

1. **RestClientProvider.cs** (1 line changed):
   - Line 862: Changed from `statusCode < 300` to `statusCode < 400`
   - Allows 3xx redirect status codes to be treated as success responses

2. **Unit test**:
- Added `Validate3xxRedirectStatusCode` test in
`RestClientProviderTests.cs` to verify 302 redirect support
- Test validates proper pipeline message classifier creation for 3xx
status codes
- Test validates that the CreateRequest method properly references and
uses the classifier property
   - Test is self-contained and uses InputFactory to create test data

### Test Results

✅ All 1010 unit tests pass
(Microsoft.TypeSpec.Generator.ClientModel.Tests)
✅ New test specifically validates 302 redirect functionality including
CreateRequest method behavior
✅ No regressions in existing functionality

### Migration Blocker Resolution

This resolves the migration blocker for
Azure.Communication.ProgrammableConnectivity which uses 302 redirects in
its OAuth authorization flow. The service can now migrate from the
legacy emitter to http-client-csharp v1.0.0+.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Add support for 302 redirect</issue_title>
> <issue_description>See
https://github.com/Azure/azure-sdk-for-net/blob/8401911d737002189207067dde4177ea94846126/sdk/communication/Azure.Communication.ProgrammableConnectivity/MIGRATION_BLOCKER.md</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9497

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* Migrate Create-APIReview script from API Key to Azure AD authentication (#9501)

- [x] Review Azure SDK PR #13235 pattern for removing API Key
authentication
- [x] Update Create-APIReview.ps1 to remove API Key parameter and add
Bearer token authentication
  - Removed `$APIKey` parameter from script
- Added `Get-ApiViewBearerToken()` function that acquires Azure AD
tokens via `az account get-access-token`
- Updated `Upload-SourceArtifact` to use Bearer token instead of API Key
- Updated `Upload-ReviewTokenFile` to use Bearer token instead of API
Key
- Changed API endpoints from `UploadAutoReview` to `upload` and
`CreateApiReview` to `create` (lowercase)
  - Changed HTTP method from GET to POST for the create endpoint
  - Improved error handling with more detailed error messages
- [x] Update create-apireview.yml to use AzureCLI@2 task instead of
Powershell@2 task
  - Changed task from `Powershell@2` to `AzureCLI@2`
- Added `AzureServiceConnection` parameter with default value "APIView
prod deployment"
  - Removed `-APIKey $(azuresdk-apiview-apikey)` argument
  - Removed `pwsh: true` (not needed with AzureCLI@2)
  - Added `azureSubscription`, `scriptType`, and `scriptLocation` inputs
- [x] Address security concern: removed potentially sensitive token
response from error logging

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Stop using Api Key in Create-ApiReview
script</issue_title>
> <issue_description>We can follow the same pattern as used in
https://github.com/Azure/azure-sdk-tools/pull/13235
> 
> And apply those changes to
https://github.com/microsoft/typespec/blob/main/eng/emitters/scripts/Create-APIReview.ps1
> 
> Also need to update
https://github.com/microsoft/typespec/blob/main/eng/emitters/pipelines/templates/steps/create-apireview.yml</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9500

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* Rename from "top" to "maxCount" in paging operations (#9505)

This pull request updates the C# HTTP client generator to improve
parameter naming consistency for paging operations. Specifically, it
ensures that the "top" query parameter is renamed to "maxCount" in
generated REST client methods, and adds a corresponding unit test to
verify this behavior. Additionally, the `InputParameter.Update` method
is enhanced to allow updating multiple fields at once.

Solves: https://github.com/microsoft/typespec/issues/9502

* [python] release new version (#9507)

* Fix optional Content-Type headers being transformed to enums (emitter-only) (#9495)

Optional Content-Type headers were incorrectly transformed into
extensible enums by the type converter. They must remain as constants.

## Changes

**Emitter (type-converter.ts)**
- Skip enum transformation for Content-Type headers, preserving constant
type regardless of optionality

**Emitter (operation-converter.ts)**
- Pass header parameter to `fromSdkType` to enable Content-Type
detection

**Emitter Tests (operation-converter.test.ts)**
- Added tests to verify Content-Type remains as constant type for both
optional and required bodies

## Result

Content-Type headers now remain as constants in the type model instead
of being transformed to enums when the body parameter is optional. This
prevents the enum transformation while preserving the constant type
information for downstream processing.

## Note

This PR focuses solely on the emitter-side fix to prevent unwanted enum
transformation. Generator-side handling of optional Content-Type
parameters (if needed for conditional setting) will be addressed
separately.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Fix optional contentType issue</issue_title>
> <issue_description>As described in
https://github.com/Azure/azure-sdk-for-net/issues/55300, but the issue
belongs in this repo.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9494

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>
Co-authored-by: jolov <jolov@microsoft.com>

* Changes to .chronus shouldn't trigger core CI (#9496)

Co-authored-by: iscai-msft <43154838+iscai-msft@users.noreply.github.com>

* Allow configuring options in snapshot samples (#9460)

To reduce changes in https://github.com/Azure/typespec-azure/pull/3836

* Astro utils updates (#9491)

- Move EditorTabs component for reuse in typespec-azure
- Make sure the tryit plugin works correctly when using `<Code`
component

* Fix unknown scalar constructors crashing openapi3 (#9475)

fix #9394

* [python] correctly cache enum members (#9517)

Co-authored-by: iscai-msft <isabellavcai@gmail.com>

* Bump System.ClientModel to 1.9.0 (#9519)

Updates System.ClientModel package from 1.8.0 to 1.9.0 in both generator
source and generated project templates.

## Changes

- **Packages.Data.props**: Updated `System.ClientModel` to 1.9.0 and
`System.Memory.Data` to 10.0.1 (transitive dependency requirement)
- **NewProjectScaffolding.cs**: Updated generated project template to
reference System.ClientModel 1.9.0
- Regenerated all test projects (74 .csproj files) to reflect the new
package versions

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Bump SCM to 1.9.0</issue_title>
> <issue_description>Bump System.ClientModel package to 1.9.0 both in
our [generator
source](https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/Packages.Data.props#L17)
and in the generated project file.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9518

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: jorgerangel-msft <102122018+jorgerangel-msft@users.noreply.github.com>

* [python] release new version (#9525)

* Bump tar from 7.5.3 to 7.5.7 in /packages/http-client-java (#9524)

Bumps [tar](https://github.com/isaacs/node-tar) from 7.5.3 to 7.5.7.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/isaacs/node-tar/commit/4a37eb9a1cf1137df4eb70c5c7f849f412ff3cdb"><code>4a37eb9</code></a>
7.5.7</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/f4a7aa9bc3d717c987fdf1480ff7a64e87ffdb46"><code>f4a7aa9</code></a>
fix: properly sanitize hard links containing ..</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/394ece6ad8d81742a4e4058af227c616cd947a25"><code>394ece6</code></a>
7.5.6</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/7d4cc17c76f6bd11dcd83de47187dc6dff206eee"><code>7d4cc17</code></a>
fix race puting a Link ahead of its target File</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/26ab90474e642cf00d84a05bcdc2eaf2a19f1581"><code>26ab904</code></a>
7.5.5</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/e9a1ddb821b29ddee75b9470dd511066148c8070"><code>e9a1ddb</code></a>
fix: do not prevent valid linkpaths within archive</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/911c886bb170a6ee3db05fd3709221752213ec8a"><code>911c886</code></a>
7.5.4</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/3b1abfae650056edfabcbe0a0df5954d390521e6"><code>3b1abfa</code></a>
normalize out unicode ligatures</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/a43478c5c51a71ec996cea62ff824eb9dc9dd17c"><code>a43478c</code></a>
remove some unused files</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/970c58f6d3d0c932081f8b40218f612db2fabb5a"><code>970c58f</code></a>
update deps</li>
<li>Additional commits viewable in <a
href="https://github.com/isaacs/node-tar/compare/v7.5.3...v7.5.7">compare
view</a></li>
</ul>
</details>
<details>
<summary>Maintainer changes</summary>
<p>This version was pushed to npm by <a
href="https://www.npmjs.com/~isaacs">isaacs</a>, a new releaser for tar
since your current version.</p>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tar&package-manager=npm_and_yarn&previous-version=7.5.3&new-version=7.5.7)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/microsoft/typespec/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Fix optional Content-Type header detection by unifying parameter processing (#9528)

- [x] Understand the issue: The previous fix in PR #9495 added
Content-Type header detection in `type-converter.ts`, but it relies on
`sdkProperty` being passed to `fromSdkType`. The `fromHeaderParameter`
function in `operation-converter.ts` doesn't pass the header parameter
to `fromSdkType`, so the fix doesn't work.
- [x] Fix `fromHeaderParameter` to pass the header parameter `p` to
`fromSdkType` so the Content-Type detection can work
- [x] Unify all parameter-processing functions to pass property instance
to `fromSdkType`:
  - `fromQueryParameter`
  - `fromPathParameter`
  - `fromHeaderParameter`
  - `fromBodyParameter`
  - `updateMethodParameter`
- [x] Investigated making `sdkProperty` required - not feasible as many
callers have no property context (model base types, array/dict value
types, etc.)
- [x] Run existing tests to verify the fix works (all 177 tests pass)
- [x] Fix CI formatting issues
- [x] Run code review and security checks

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Fix optional contentType issue</issue_title>
> <issue_description>As described in
https://github.com/Azure/azure-sdk-for-net/issues/55300, but the issue
belongs in this repo.</issue_description>
> 
> <agent_instructions>The previous [fix
](https://github.com/microsoft/typespec/pull/9495) does not really fix
the issue entirely.
> Please fix this again following the root cause in this comment:
https://github.com/microsoft/typespec/issues/9494#issuecomment-3822513806</agent_instructions>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> <comment_new><author>@ArcturusZhang</author><body>
> I think this is not fixed.
> The fix introduced an extra check to see if it is a content type
header, by checking if the `sdkProperty` is not undefined, but in our
code, when the `fromSdkType` is called converting the method parameters
(for instance
[here](https://github.com/microsoft/typespec/blob/f1a7649b3b53ab7d30488cf7274f813696cdf2d0/packages/http-client-csharp/emitter/src/lib/operation-converter.ts#L482)),
the `sdkProperty` argument is never passed in. Therefore the fix is not
actually running.</body></comment_new>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9494

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ArcturusZhang <10554446+ArcturusZhang@users.noreply.github.com>

* Add backward compatibility for object-typed AdditionalProperties (#9516)

## ✅ Implementation Complete: Add backward compatibility support for
object-typed AdditionalProperties

### Issue Resolved
Successfully implemented backward compatibility for models with
`IDictionary<string, object>` AdditionalProperties (from old generator)
that are now generated as `IDictionary<string, BinaryData>` (in new
generator).

### Final Solution

**Core Approach: Matching Backing Field Types**

The solution detects when a model previously had object-typed
AdditionalProperties and creates the backing field with the appropriate
type, ensuring perfect type alignment between field and property.

### Files Changed


**packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Providers/ModelProvider.cs**
- Added object dictionary type support alongside BinaryData
- Added early backward compatibility detection via
`ShouldUseObjectAdditionalProperties()`
- Updated `BuildRawDataField()` to create field with object or
BinaryData type based on backward compat needs
- Updated property generation logic to use matching backing field type
- Added comprehensive XML documentation
- Fixed null-safety issues with IsFrameworkType checks


**packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/test/Providers/ModelProviders/ModelProviderTests.cs**
- Added
`TestBuildProperties_WithObjectAdditionalPropertiesBackwardCompatibility`
test


**packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/test/Providers/MrwSerializationTypeDefinitions/AdditionalPropertiesTest.cs**
- Added comprehensive deserialization test verifying all code aspects
- Added comprehensive serialization test verifying all code aspects
- Both tests validate complete generated code with detailed assertions

**packages/http-client-csharp/generator/docs/backward-compatibility.md**
- Added new section "AdditionalProperties Type Preservation"
- Documents the object-to-BinaryData migration scenario
- Provides examples of before/after code
- Explains serialization/deserialization behavior differences
- Formatted with prettier (removed trailing whitespace)

### Test Results ✅

- **1232/1232** Microsoft.TypeSpec.Generator.Tests PASSED
- **1014/1014** Microsoft.TypeSpec.Generator.ClientModel.Tests PASSED
- **10/10** AdditionalPropertiesTest tests PASSED
- **2/2** Serialization backward compatibility tests with comprehensive
assertions PASSED

### Comprehensive Test Coverage

**Deserialization test verifies:**
- Variable declaration: `IDictionary<string, object>
additionalProperties`
- Dictionary initialization: `ChangeTrackingDictionary<string,
object>()`
- Property enumeration: `foreach (var prop in
element.EnumerateObject())`
- Property name checks: `prop.NameEquals("name"u8)`
- Type-specific methods: `GetString()` for known properties,
`GetObject()` for additional properties
- Constructor call with proper parameters

**Serialization test verifies:**
- Format validation and error handling
- Property name serialization: `writer.WritePropertyName("name"u8)`
- Property value serialization: `writer.WriteStringValue(Name)`
- Foreach iteration over AdditionalProperties
- Key serialization: `writer.WritePropertyName(item.Key)`
- Value serialization: `writer.WriteObjectValue<object>(item.Value,
options)`
- Options.Format handling

### Backward Compatibility Guarantees

| Scenario | Result |
|----------|--------|
| Existing library with object type | ✅ Maintains object type when
regenerated |
| New library without previous version | ✅ Uses BinaryData type (new
default) |
| Binary compatibility | ✅ Fully maintained - same types |
| Source compatibility | ✅ Fully maintained - code compiles |
| Serialization | ✅ Works with both types - fully verified |
| Deserialization | ✅ Works with both types - fully verified |

### Ready for Merge

This PR successfully resolves the issue with comprehensive test coverage
and documentation updates.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Add backcompat support for public AdditionalProperties
property on models defined as object valued dictionary</issue_title>
> <issue_description>In the old generator, we would generate
AdditionalProperties as `IDictionary<string, object>`. In the new
generator, we use `IDictionary<string, BinaryData>`. We will need to
implement support for object for backwards
compatibility.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9515

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* Fix Content-Type header set when request content is optional (#9521)

## Fix Content-Type header setting in RestClient ✅

### Summary
Fixed an issue where Content-Type headers were set unconditionally, even
when request content was optional and might be null.

### Changes Made
- [x] Modified `RestClientProvider.BuildCreateRequestMethodBody` to
detect and pass content parameter to `AppendHeaderParameters`
- [x] Updated `AppendHeaderParameters` to wrap Content-Type header
setting in `if (content != null)` check **only when body parameter is
optional**
- [x] Added comprehensive tests to verify the fix with full statement
assertion
- [x] Added test for required body parameter with assertion that
Content-Type is NOT wrapped in if statement
- [x] Removed unnecessary cast - ParameterProvider has implicit
conversion to ValueExpression
- [x] All 51 RestClientProvider tests passing

### Result
**Before:**
```csharp
// When body is optional
request.Headers.Set("Content-Type", "application/json");
request.Content = content;  // content could be null
```

**After (when body is optional):**
```csharp
if (content != null)
{
    request.Headers.Set("Content-Type", "application/json");
}
request.Content = content;
```

**After (when body is required):**
```csharp
request.Headers.Set("Content-Type", "application/json");
request.Content = content;  // content is required, no null check needed
```

This ensures Content-Type headers are only wrapped in null checks when
the request body parameter is actually optional, avoiding unnecessary
checks for required parameters.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Content-Type setting in RestClient is not
correct</issue_title>
> <issue_description>Currently we have code generated like this
https://github.com/Azure/azure-sdk-for-net/pull/55347#discussion_r2743823430.
This isn't correct (obviously). We should instead be checking if the
RequestContent is null when setting the Content-Type header.
> </issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9520

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* fix: date time offset formatting was culture variant for doc comments (#9538)

while onboarding to the project, I noticed a failing unit test on
windows (en-CA) locale. This is due to a variant behaviour on how dates
are represented

* ci: adds @shivangiReja and @joseharriaga to the csharp reviewers (#9539)

while working on #9538 I noticed they were missing. Note: using teams
here would make things easier

* APIVersion and MaxpAgeSize Parameter handling (#9523)

This pull request refactors how special query parameters, particularly
API version and max page size, are detected and handled in the
`RestClientProvider` class. The changes improve the flexibility and
accuracy of parameter updates, especially for paging operations, by
relying on parameter metadata rather than hardcoded string comparisons.

Parameter handling improvements:

* Refactored the logic for detecting API version and max page size
parameters in `ShouldUpdateReinjectedParameter` to use parameter
metadata (`IsApiVersion` and paging metadata) instead of comparing
against hardcoded strings.
* Updated the call to `ShouldUpdateReinjectedParameter` in
`AppendQueryParameters` to pass the full `InputParameter` and
`InputPagingServiceMethod`, enabling the new metadata-based logic.

* Add support for array encoding with @encode(ArrayEncoding.*) decorator (#9430)

This pull request adds support for custom array encoding formats in the
C# HTTP client generator, allowing arrays to be serialized and
deserialized using delimiters such as comma, space, pipe, or newline.
The changes span the model, serialization logic, type conversion, and
test coverage to ensure correct handling of these encodings.

### Array encoding support

* Introduced an optional `encode` property to `InputModelProperty` and
related types to specify the desired array encoding (e.g.,
`commaDelimited`, `spaceDelimited`, etc.). This is reflected in the type
definitions, model constructors, and JSON serialization/deserialization
logic.
* Updated the type converter (`type-converter.ts`) to propagate the
`encode` property from SDK model properties into the input model.

### Serialization and deserialization logic

* Added custom serialization and deserialization methods in
`MrwSerializationTypeDefinition.cs` to handle arrays with specified
encodings. These methods join or split array elements using the
appropriate delimiter and handle both string and primitive element
types.

### Test coverage

* Added new tests in `EncodeArrayTests.cs` to verify correct
serialization and deserialization for each supported encoding format
(comma, space, pipe, newline).


Implements: https://github.com/microsoft/typespec/issues/9028

* Bump tar from 7.5.6 to 7.5.7 in /packages/http-client-csharp (#9544)

Bumps [tar](https://github.com/isaacs/node-tar) from 7.5.6 to 7.5.7.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/isaacs/node-tar/commit/4a37eb9a1cf1137df4eb70c5c7f849f412ff3cdb"><code>4a37eb9</code></a>
7.5.7</li>
<li><a
href="https://github.com/isaacs/node-tar/commit/f4a7aa9bc3d717c987fdf1480ff7a64e87ffdb46"><code>f4a7aa9</code></a>
fix: properly sanitize hard links containing ..</li>
<li>See full diff in <a
href="https://github.com/isaacs/node-tar/compare/v7.5.6...v7.5.7">compare
view</a></li>
</ul>
</details>
<details>
<summary>Maintainer changes</summary>
<p>This version was pushed to npm by <a
href="https://www.npmjs.com/~isaacs">isaacs</a>, a new releaser for tar
since your current version.</p>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=tar&package-manager=npm_and_yarn&previous-version=7.5.6&new-version=7.5.7)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/microsoft/typespec/network/alerts).

</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Fix duplicate discriminator property in derived types with matching serialized names (#9477)

- [x] Investigate the issue and understand the root cause
- [x] Write failing tests that reproduce the bug
- [x] Fix the issue by comparing serialized names instead of C# property
names for discriminator de-duplication
- [x] Verify all related tests pass (1233 generator tests)
- [x] Run code review and address feedback
- [x] Add null checks for SerializedName as suggested in review
- [x] Add verification that correct discriminator value is passed to
base class

## Root Cause Analysis
The bug occurs in `ModelProvider.BuildProperties()` where the check for
duplicate discriminator properties only compared by C# property name
(`property.Name`) instead of also checking the serialized name
(`property.SerializedName`).

When the base model has a discriminator property with a different C#
name than the derived model's discriminator property (but the same wire
name like `@odata.type`), the check failed and the discriminator
property was incorrectly added to the derived class.

## Fix
Added a HashSet of base discriminator serialized names and extended the
check to skip discriminator properties that match by either:
1. C# property name (existing check)
2. Serialized name (new check)

Added null checks for `SerializedName` as per code review feedback to
ensure defensive coding practices.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>[Bug]: Duplicate Discriminator Property in Derived
Types</issue_title>
> <issue_description>### Describe the bug
> 
> ### Description
> The TypeSpec C# generator creates a duplicate `OdataType` property in
derived classes when the base class already defines it as the
discriminator. This causes CS0108 "hides inherited member" compiler
warnings/errors.
> 
> ### Reproduction
> In `ContentUnderstandingSkill.cs` (derived from `SearchIndexerSkill`):
> 
> **Base class (`SearchIndexerSkill.cs`):**
> ```csharp
> internal string OdataType { get; set; }
> ```
> 
> **Derived class (`ContentUnderstandingSkill.cs`) incorrectly
re-declares:**
> ```csharp
> internal string OdataType { get; set; } =
"#Microsoft.Skills.Util.ContentUnderstandingSkill";
> ```
> 
> The internal constructor also has a redundant parameter:
> ```csharp
> internal ContentUnderstandingSkill(
>     string odataType,           // ? passed to base class
>     ...,
> string odataType0) // ? duplicate, assigned to local OdataType
>     : base(odataType, ...)
> {
>     // ...
>     OdataType = odataType0;     // ? This shouldn't exist
> }
> ```
> 
> ### Expected Behavior
> Derived types should NOT re-declare the discriminator property. The
value should be set via the base class constructor only, which is
already being done correctly in the public constructor:
> 
> ```csharp
> public ContentUnderstandingSkill(...) 
> : base("#Microsoft.Skills.Util.ContentUnderstandingSkill", inputs,
outputs)
> ```
> 
> ### Compiler Error
> ```
> CS0108: 'ContentUnderstandingSkill.OdataType' hides inherited member
'SearchIndexerSkill.OdataType'.
> Use the new keyword if hiding was intended.
> ```
> 
> ### Root Cause
> The TypeSpec definition likely has the `@odata.type` discriminator
property appearing in both the base type and derived type definitions,
or there's a conflict between the discriminator and a regular property
with the same JSON name.
> 
> ### Affected Types
> - `ContentUnderstandingSkill`
> - `ChatCompletionSkill`
> - Potentially all derived skill types and any other polymorphic
hierarchy with a discriminator property
> 
> ---
> 
> ### Reproduction
> 
> Existing File with error :
https://github.com/Azure/azure-sdk-for-net/blob/3df80e71cc22102f60910e9d188ca864ea18849d/sdk/search/Azure.Search.Documents/src/Generated/Models/ChatCompletionSkill.cs#L138C1-L139C1
> 
> Previous file:
https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/search/Azure.Search.Documents/src/Generated/Models/ChatCompletionSkill.cs
> 
> ### Checklist
> 
> - [x] Follow our [Code of
Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md)
> - [x] Check that there isn't already an issue that request the same
bug to avoid creating a duplicate.
> - [x] Check that this is a concrete bug. For Q&A open a [GitHub
Discussion](https://github.com/Microsoft/typespec/discussions).
> - [x] The provided reproduction is a [minimal reproducible
example](https://stackoverflow.com/help/minimal-reproducible-example) of
the bug.</issue_description>
> 
> <agent_instructions>This fix applies to
packages\http-client-csharp</agent_instructions>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9437

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JonathanCrd <17486462+JonathanCrd@users.noreply.github.com>
Co-authored-by: Jonathan Cárdenas <JonathanCrd@users.noreply.github.com>

* [Python][Docs] Add architecture documentation for http-client-python emitter (#9274)

- [x] Explore the http-client-python repository structure
- [x] Understand the emitter and generator architecture
- [x] Review existing documentation and structure
- [x] Create comprehensive architecture documentation
- [x] Add the documentation to the website
- [x] Review and finalize documentation
- [x] Fix ASCII diagram box alignment
- [x] Add m2r transformation to emitter responsibilities
- [x] Align directory structure comments
- [x] Ensure all diagram right borders align at column 66
- [x] Align all # comments to column 43 in directory tree
- [x] Simplify component details to reduce duplication
- [x] Fix Prettier formatting issues

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>[python] docs to introduce source code of
http-client-python</issue_title>
> <issue_description>Context:
> http-client-python contains 2 part of code,
> (1) first part is in folder "emitter" written by typescript which
handle info from typespec-client-generator-code, then pass handled data
to "generator/pygen" written by python to generate sdk.
> (2) In pygen, it is pre-handled again in "preprocess" then pass to
"codegen". In "codegen", "models" prepares all necessary info then
"serializers" render files with template files of "templates" and
parameter info from "models" to generated sdk file.
> 
> Ask:
> With up context, write a brief introduction to "http-client-python" so
that developers could understand the repo and develop quickly.
> 
> NOTE:
> (1) context is just help you understand the repo but DO NOT be limited
by context so you can read the files or code of this repo to make a good
doc
> </issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9273

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for
you](https://github.com/microsoft/typespec/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.

---------

Co-authored-by: Yuchao Yan <yuchaoyan@microsoft.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>
Co-authored-by: msyyc <70930885+msyyc@users.noreply.github.com>

* http-client-java, bug fix on mock value for BinaryData (#9527)

fix https://github.com/microsoft/typespec/issues/9508

* http-client-java, support File (#9530)

https://github.com/microsoft/typespec/issues/9509

* Minify and gzip bundler output (#9536)

Right now files targetted for playground usage are not minified. This
makes the playground loading slower

* Remove type and optionality constraints from @continuationToken decorator (#9078)

The `@continuationToken` decorator enforced that properties be of type
`string`, preventing nullable types like `string | null` and rejecting
non-string types entirely. This constraint was unnecessarily restrictive
for pagination patterns.

### Changes

- **`packages/compiler/src/lib/paging.ts`**: Removed validation function
from `continuationTokenDecorator` that enforced string type requirement
- **`packages/compiler/test/decorators/paging.test.ts`**: Added tests
covering nullable types, optional properties, and non-string types

### Usage

The decorator now accepts any type without validation:

```typespec
model ListPageInfo {
  @pageItems items: string[];
  
  // Now supported: nullable non-optional
  @continuationToken endCursor: string | null;
  
  // Already worked, still works: optional
  @continuationToken token?: string;
  
  // Now supported: non-string types
  @continuationToken offset: int32;
}
```

Backward compatible - all existing usage continues to work unchanged.

<!-- START COPILOT CODING AGENT SUFFIX -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>[Bug]: Continuation token must allow nullable non
optional fields</issue_title>
> <issue_description>### Describe the bug
> 
> Currently `@continuationToken` supports only string type for the
field. Like this.
> 
> ```typespec
> model ListPageInfo {
>     startCursor?: string;
> 
>     @continuationToken
>     endCursor?: string;
> 
>     hasNext: boolean;
>     hasPrev: boolean;
> }
> ```
> 
> While having optional field is fine, for typescript case, to enforce
more consistent typing I prefer to make fields nullable instead,
therefore compiler would highlight missing expected nullable field.
> 
> Therefore `@continuationToken` should support more than field
optionality way of representing the token which might be or might not
be, but the field is always present otherwise.
> 
> ### Reproduction
> 
> ```typespec
> model ListPageInfo {
>     startCursor?: string;
> 
>     @continuationToken
>     endCursor: string | null;
> 
>     hasNext: boolean;
>     hasPrev: boolean;
> }
> ```
> 
> decorator gives: 
> ```Cannot apply continuationToken decorator to string | null since it
is not assignable to stringTypeSpec(decorator-wrong-target)```
> 
> ### Checklist
> 
> - [x] Follow our [Code of
Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md)
> - [x] Check that there isn't already an issue that request the same
bug to avoid creating a duplicate.
> - [x] Check that this is a concrete bug. For Q&A open a [GitHub
Discussion](https://github.com/Microsoft/typespec/discussions).
> - [x] The provided reproduction is a [minimal reproducible
example](https://stackoverflow.com/help/minimal-reproducible-example) of
the bug.</issue_description>
> 
> <agent_instructions>Remove the constraint that requires the target
property of `@continuationToken` to be a string *and* the constraint
that requires it to be a required property. Correct any tests and add
new tests to verify that an optional property cna be marked with this
decorator.</agent_instructions>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> <comment_new><author>@timotheeguerin</author><body>
> This feels resonable, not sure it should even force it to be a
string</body></comment_new>
> </comments>
> 


</details>

- Fixes microsoft/typespec#9044

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: markcowl <1054056+markcowl@users.noreply.github.com>
Co-authored-by: Timothee Guerin <tiguerin@microsoft.com>

* Fix PipelineMessageClassifier property caching to use ??= instead of = (#9556)

PipelineMessageClassifier properties were reallocating on every access
instead of caching in their backing fields due to using simple
assignment.

**Before:**
```csharp
private static PipelineMessageClassifier PipelineMessageClassifier200 
    => _pipelineMessageClassifier200 = PipelineMessageClassifier.Create(stackalloc ushort[] { 200 });
```

**After:**
```csharp
private static PipelineMessageClassifier PipelineMessageClassifier200 
    => _pipelineMessageClassifier200 ??= PipelineMessageClassifier.Create(stackalloc ushort[] { 200 });
```

### Changes

- **Generator**: Added `nullCoalesce: true` to `Assign()` call in
`RestClientProvider.cs:356`
- **Test data**: Updated expected output in 3 test files to match new
`??=` pattern
- **Generated samples**: Updated 10 files in `docs/samples` and
`TestProjects` to reflect corrected generation

The null-coalescing assignment ensures `Create()` is called once on
first access rather than on every property access.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>Don't reallocate PipelineMesssageClassifier properties on
each access</issue_title>
> <issue_description>We intended to cache the value in the backing
field.
> 
>
https://github.com/Azure/azure-sdk-for-net/pull/54611#discussion_r2733976282</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9555

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for
you](https://github.com/microsoft/typespec/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>
Co-authored-by: jolov <jolov@microsoft.com>

* Fix listing files when multiople instance are loaded (#9320)

fix #9313

---------

Co-authored-by: Mark Cowlishaw <1054056+markcowl@users.noreply.github.com>

* Fix Openapi3.0 param with $ref schema and default (#9533)

fix [#8781](https://github.com/microsoft/typespec/issues/8781)

* Fix content-type consistency in payload/xml XmlErrorValue response (#9570)

`XmlErrorValue.get()` returned `SimpleModel` without a content-type
header (defaulting to `application/json`) while `XmlError` used
`application/xml`. This inconsistency is unexpected for an XML payload
spec.

### Changes
- Wrap `SimpleModel` response with explicit `application/xml`
content-type header to match the error response

**Before:**
```tsp
get(): SimpleModel | XmlError;
```

**After:**
```tsp
get(): {
  @header("content-type") contentType: "application/xml";
  @body body: SimpleModel;
} | XmlError;
```

This follows the same pattern used by `XmlOperations<TModel>` template
elsewhere in the file.

> [!WARNING]
>
> <details>
> <summary>Firewall rules blocked me from connecting to one or more
addresses (expand for details)</summary>
>
> #### I tried to connect to the following addresses, but was blocked by
firewall rules:
>
> - `telemetry.astro.build`
> - Triggering command: `/usr/local/bin/node node
/home/REDACTED/work/typespec/typespec/website/node_modules/.bin/../astro/astro.js
build node sion��
ebsite/src/content/docs/docs/emitters/openapi3/reference node e
--no-emit sh rsioning/referentspd doc . --enable-experimental
--output-dir ../../website/src/content/docs/d--output-dir node p/no��
ite...&#34; --filter &#34;!@typespec/monorepo&#34; run regen-docs uname
/node_modules/.bin/node &amp;&amp; pnpm lint-tysh node
_modules/pnpm/ditsx ./.scripts/regen-compiler-docs.ts tp/reference` (dns
block)
>
> If you need me to access, download, or install something from one of
these locations, you can either:
>
> - Configure [Actions setup
steps](https://gh.io/copilot/actions-setup-steps) to set up my
environment, which run before the firewall is enabled
> - Add the appropriate URLs or hosts to the custom allowlist in this
repository's [Copilot coding agent
settings](https://github.com/microsoft/typespec/settings/copilot/coding_agent)
(admins only)
>
> </details>

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>[spector] fix case for payload/xml</issue_title>
> <issue_description>For
https://github.com/microsoft/typespec/blob/afa236acbbaa468a8910e8fc4177828ed174d8ba/packages/http-specs/specs/payload/xml/main.tsp#L332,
> - `SimpleModel` is not wrapped with content-type header
"application/xml" then its default content-type is "application/json"
> - `XmlError` defines content-type header as "application/xml"
> 
> It is very strange that response and error response has such different
content-type.
> 
> **Expected behavor**:
> 
> We expect `SimpleModel` shall also be wrapped with content-type
"application/xml" to keep consistent with error response like other
cases in this file
> 
> **NOTE**:
> 
> 1. DO add changelog under .chronus/changes
> 2. DO necessary check before commit.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes microsoft/typespec#9569

<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions,
customizing its development environment and configuring Model Context
Protocol (MCP) servers. Learn more [Copilot coding agent
tips](https://gh.io/copilot-coding-agent-tips) in the docs.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: msyyc <70930885+msyyc@users.noreply.github.com>

* [Python] optimize perf for test generation and sample generation (#9473)

for https://github.com/microsoft/typespec/issues/9448

PR summary:
- The main optimization is to cache the cost operation in
`import_sample_cache` and `import_test_cache` so that they could be
reused in test generation and sample generation. The more test/samples
to generate, the more time to save. For example, cost time of SDK
generation for Apimanagement is reduced from 47 minutes to 4 minutes.

* [python] Remove deepcopy from import_serializer.py (#9551)

For https://github.com/microsoft/typespec/issues/9486

Eliminating `deepcopy` can enhance the speed of generating the Python
SDK for complex packages by 20%.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: msyyc <70930885+msyyc@users.noreply.github.com>
Co-authored-by: Yuchao Yan <yuchaoyan@microsoft.com>

* [python] ignore all errors during error deserialization (#9573)

Co-authored-by: iscai-msft <isabellavcai@gmail.com>

* [python] bump for release (#9574)

Co-authored-by: iscai-msft <isabellavcai@gmail.com>

* [python][Doc] skill to help bump and release (#9424)

According to
https://code.visualstudio.com/docs/copilot/customization/agent-skills#_create-a-skill,
we could add skill to help bump and release http-client-python

* feat: Remove internal tag from openapi-versions property for emitter (#9584)

follow up to #4946 now that both 3.1.0 and 3.2.0 are implemented, the
property should be exposed.

---------

Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: baywet <7905502+baywet@users.noreply.github.com>

* Generator fix to handle apiVersion casing and multiple placeholders in URI path (#9561)

Make paramMap look up case insensitive to avoid cases like
```"ApiVersion"``` in server parameters vs ```"apiVersion"```. Fix
template for URI path to be compatible with multiple placeholders like
```"{Endpoint}/anomalydetector/{ApiVersion}"```.

---------

Co-authored-by: Linh Phan <mailinhphan@microsoft.com>

* handled paging parameter casing (#9567)

This pull request improves the handling of page size parameter names in
the C# HTTP client generator to ensure correct casing and compatibility
with previous contract versions. The changes introduce logic to preserve
parameter casing from the previous contract when available and to
normalize common variants (like "maxpagesize") to the standard
"maxPageSize" otherwise. Comprehensive tests are added to verify this
behavior.

Resolves: https://github.com/Azure/azure-sdk-for-net/issues/54468

* Fix malformed namespace generation for unresolved types in customization code (#9578)

## Fix for Malformed Namespace Generation in Customization Code

- [x] Understand root cause: Roslyn cannot resolve generated types in
customization code, leading to malformed namespaces
- [x] Move fix from TypeSymbolExtensions to
CSharpTypeExtensions.EnsureNamespace per code review feedback
- [x] Enhanced EnsureNamespace to look up types by name when spec
property is null
- [x] Handle edge case where types are renamed with CodeGenType
attribute
- [x] Add TypeProvidersByName dictionary for efficient name-based lookup
- [x] Remove redundant code and unnecessary variables
- [x] Add comprehensive tests validating the fix
- [x] Validate with existing test suite - all 2260 tests pass (including
2 new tests)

### Changes Made

**Modified:** `TypeFactory.cs`
- Added `TypeProvidersByName` dictionary mapping C# type names to
TypeProviders for efficient O(1) lookup
- Populated dictionary when adding types to CSharpTypeMap in CreateModel
and CreateEnum

**Modified:** `CSharpTypeExtensions.cs`
- Enhanced `EnsureNamespace` method to handle custom properties without
corresponding spec properties
- Added `TryFindCSharpTypeByName` with inline TypeFactory access for
cleaner code
- Returns properly qualified CSharpType by resolving through
TypeProvidersByName

**Added Tests:** `ModelCustomizationTests.cs`
- `CanAddPropertyReferencingGeneratedType`: Validates custom property
`IList<Bar>` gets proper namespace "Sample.Models"
- `CanAddPropertyReferencingRenamedGeneratedType`: Validates custom
property referencing CodeGenType renamed type gets proper namespace
- Both tests confirm namespaces are correctly resolved instead of being
empty or malformed

### Testing
All tests pass, confirming the fix resolves malformed namespace
generation for customization code.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>[http-client-csharp] malformed code is generated on some
kind of customization code</issue_title>
> <issue_description>Sometimes, in customized code, roslyn cannot
analyze the correct namespace of some symbols (or maybe not?), and code
like this is generated:
> <img width="1850" height="878" alt="Image"
src="https://github.com/user-attachments/assets/1630f69a-b9c1-49f6-8073-386152826431"
/>
> 
> We need to fix this.
> The above code was generated when we have the following customization:
> <img width="1613" height="694" alt="Image"
src="https://github.com/user-attachments/assets/f1df4239-5382-4acd-8e76-13dcd72c707f"
/>
> 
> To reproduce:
> Prepare typespec:
> ```
> model Foo {
> 	bar?: Bar;
> }
> 
> model Bar {
> 	b?: string;
> }
> ```
> In the generated code, add the following:
> ```
> [CodeGenSerialization(nameof(Bars), "bars"]
> public partial class Foo
> {
> 	public IList<Bar> Bars {get;}
> }
> ```
> then generate the code.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> <comment_new><author>@JoshLove-msft</author><body>
> @ArcturusZhang can you please add repro
instructions?</body></comment_new…